In the telecommunications industry (switching, transport, and network management), the key requirements for the craft user interface (CUI) are
a) fast, b) reliable, c) easy to use and d) connectivity. The user interface should be simple and easy to use. A simple interface helps to reduce procedural errors, outages, and is easy to learn. The information (the content and presentation) viewed at different nodes should be identical. Connectivity is the ability to access any node in a network via remote login procedures. For example, access to transport nodes from surveillance centers or from one node to another node via remote login.
In 1970s and 1980s, the craft user interface (CUI) has been based on command line languages (CLL) with the principal input/output (I/O) user device being either an actual or a simulated VT100 terminal. Connectivity using the command line languages (CLL), for interconnecting nodes has been provided by the widely used Telnet protocol.
In late 1980 and in early 1990s, the prevalent connectivity (CLL) interfaces have slowly been replaced by graphical user interfaces (GUIs) with the principal I/O device being a personal computer (PC) having a mouse, which is used as a selecting device. GUIs have been found to perform much better with regard to ease of use. They have been found to offer a superior UI and to be an economical solution for the telecommunications industry. However, there has been a problem with regard to connectivity between the nodes, since there has been no replacement for the Telnet (VT100 based) protocol.
FIG. 1 illustrates a known GUI implementation based on a client-server arrangement. A GUI client 10 typically resides on a PC 12 and is implemented with Visual C++ or Visual Basic. The GUI client 10 represents the GUI engine. A server 14 represents the execution engine. Communication between the client 10 and the server 14 is typically based on proprietary protocols 16. User Interface (UI) commands are interpreted by the GUI client 10 and communicated via a proprietary protocol 16 to a server 14 on a telecommunications node 20. The server 14 communicates with applications 19 via an API 21 to execute the UI commands and then returns results to the GUI client 10. The results are then rendered on the screen of the PC 12.
The known client-server systems have used a client having either a proprietary communications protocol or a Telecommunications Language-1 (TL-1) protocol. For the GUI client with a proprietary protocol, the GUI implementation improves the simplicity and usability of the UI. However, a C++ implementation (or Visual Basic or Java implementations) results in a large program (fat GUI) that requires time and resources to design and implement. Also, since the presentation of the GUI is platform dependent, it is difficult and expensive to achieve the same presentation on different platforms having different operating systems. The connectivity requirement of being able to remotely access any node in a network could only be solved by using proprietary protocols, and implementing such protocols on all nodes in a network. As can be appreciated, design and implementation of a this type of protocol is both expensive and time consuming. Often this alternative is not practical.
A fat GUI client with the TL-1 protocol GUI implementation is similar to the above except that the connectivity is provided by the TL-1 standard protocol. This protocol had been originally designed (in 1960) for machine-to-machine communication and is based on command line languages (CLL). Consequently, it is not well suited to communicating with a GUI and may become a bottleneck in the near future.
In addition to the above problems, both the client and server software must be of the same version. Since the GUI client is developed for a PC and is distributed on diskettes (or CDs), the version of the diskette should match the version of the main software (i.e. the server) on a telecommunications node. To maintain compatibility between the client and server in the field is logistically very difficult and expensive. In practice this could lead to version control problems and the possibility of mistakes or dysfunctional UI, if the versions do not match.
Another problem with this client/server approach is each telecommunications product would require its own design and implementation of the GUI client. Consequently, the design and implementation would be expensive. Also, the user must have several GUI clients on their PC, that is one for each different product. In practice it would be difficult from both operation and maintenance points of view. The user would have to switch between different GUI clients, and would have to maintain several different GUI clients. GUI version control issues could easily lead to a situation becoming unmanageable. Clearly these problems would not be acceptable for telecommunications providers. Another problem with GUI clients that are platform dependent is cost. Each platform, e.g. PC Windows 95, Windows NT (trademarks of Microsoft Corporation), Unix (trademark of AT&T) would require a new implementation of the GUI. The overall design would be the same, but parts of the GUI client would have to be redesigned and implemented. Since, in reality, telecommunications providers are using different platforms, the telecommunications equipment vendors would have to support all platforms.
An additional problem with platform dependent GUI clients are differences in presentation. Each platform has its own way to present graphical elements. As a result, if a craft person has a PC which has a different platform than that used in the surveillance center (usually Unix engine), the presentation of the same information will be slightly different. Such differences could lead to errors in operation that would not be acceptable by telecommunications providers.
A further problem is GUI clients do not support remote logins. The ability to connect (to login) to another node, thereby performing a remote login, is a basic requirement of the craft user interface (CUI). With the GUI client-server paradigm, this requirement is very difficult to satisfy. Theoretically it is possible to develop proprietary protocols (or use the old TL-1 protocol), but in practice such solutions would be very expensive and very difficult to maintain. This would mean that GUI clients would have to be able to interpret commands of all products, leading to very large GUI clients with nearly impossible version control requirements (i.e. they would have to be in sync with many products).